How ChopChop attack against WEP actually works?

Question

From my understanding, ChopChop attack against WEP, which goal is to decrypt one packet without need to know the WEP key, goes like this:

First, the attacker takes one ciphertext message from the RF stream, addressed to the target AP. Next, he/she "chops-off" the last byte of the message, right before the ICV (which is also encrypted in the packet), and replace it with random value in range of 01 to FA. Then, the attacker finds this one changed byte position in the ICV, and calculates it to be right (because it's linear CRC-32), so the modified packet will have correct ICV checksum when it is checked by the AP during the decryption process.

The packets now is injected in the AP. The attacker listen for broadcast traffic in order to see if the packet (ARP-request, in most cases) is retransmitted again.

I can't understand, if the checksum is always correct (the attacker computes it to match to the changed with plaintext byte in the ciphertext right before packet injection in the AP), how the AP knows that the modified byte is actually wrong and doesn't match to the plaintext?

The AP will decrypt the packet (the last byte in plaintext will be ignored by the decryption algorithm, it's already in plaintext), then will compute the checksum of the plaintext, and will see if it match to the decrypted ICV value. And it will always match, because the attacker computes it right before the packet injection in the AP. So, the AP will never reject the packet?

How our AP determines that the packet with the flipped byte is corrupt?

Answer 1

Short answer

The main point to answer your question is that we need to know the original chopped off bit to be able to reconstruct the ICV. Only if we know that original bit, we can correct the altered packet so that it is accepted again.

Longer answer

AFAIK I think your assumption that

Next, he/she "chops-off" the last byte of the message, right before the ICV (which is also encrypted in the packet)

is wrong. The attacker does not know where the ICV begins, he/she just chops off the last byte of the encrypted message. However, I'm not entirely sure of this. It doesn't matter for the remainder of the answer anyway.

It is important to start the answer with two considerations:

1. It is always possible to create a corrupted packet based on a captured packet, which will be accepted by the AP (and thus of which the ICV checksum is correct)
2. The point of the ChopChop attack is not to create a corrupted packet. Its purpose is to recreate the original plaintext packet bit by bit.

I'm not going to go into detail as to why (1) is correct, please read a more mathematical guide for that. Now, we leverage mathematical findings of point (1) to arrive to the ChopChop attack. Imagine the following packet (data + icv):

0101 = data ; 11 = ICV ; full packet = 0101 11

The chopchop attack works by chopping off the last bit of the packet (so that we get 0101 1). Of course, this packet will not be accepted by the AP, as there is no way that the ICV checksum is still correct. Now the chopchop math shows that I can modify this packet so that it becomes correct again (e.g. 0101 0). It has been mathematically proven that we need the original, chopped of data bit to know how we have to modify the packet so that it will be accepted again.

So we need a calculation which uses the chopped of plaintext bit as an input. If we don't know the plaintext bit, we will not be able to know how to modify the chopped packet so that its ICV becomes correct again.

Therefore, we start guessing the chopped off bit, and we run it through the calculation, adapt the ICV, and check if the AP accepts it. If it does so, we know that we have guessed the chopped off bit. If not, we try another one.

In this answer, I have made abstraction of the encryption (I worked with plain text packets). However, due to the nature of the encryption (associative & commutative), this doesn't matter for the underlying logic, that is actually proven by point (1).